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Abstract — As the development of standards for the 
aeronautical mobile airport communications system 
(AeroMACS) progresses, the process of identifying and 
quantifying appropriate uses for the system is progressing. In 
addition to defining important elements of AeroMACS 
standards, indentifying the systems uses impacts AeroMACS 
bandwidth requirements. Although an initial 59 MHz 
spectrum allocation for AeroMACS was established in 2007, 
the allocation may be inadequate; studies have indicated that 
100 MHz or more of spectrum may be required to support 
airport surface communications. Hence additional spectrum 
allocations have been proposed. Vehicle health management 
(VHM) systems, which can produce large volumes of vehicle 
health data, were not considered in the original bandwidth 
requirements analyses, and are therefore of interest in 
supporting proposals for additional AeroMACS spectrum. 
VHM systems are an emerging development in air vehicle 
safety, and preliminary estimates of the amount of data that 
will be produced and transmitted off an aircraft, both in flight 
and on the ground, have been prepared based on estimates of 
data produced by on-board vehicle health sensors and initial 
concepts of data processing approaches. This allowed an initial 
estimate of VHM data transmission requirements for the 
airport surface. More recently, vehicle-level systems designed 
to process and analyze VHM data and draw conclusions on the 
current state of vehicle health have been undergoing testing 
and evaluation. These systems make use of vehicle system data 
that is mostly different from VHM data considered previously 
for airport surface transmission, and produce processed system 
outputs that will be also need to be archived, thus generating 
additional data load for AeroMACS. This paper provides an 
analysis of airport surface data transmission requirements 
resulting from the vehicle level reasoning systems, within the 
context of overall VHM data requirements. 
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1. Introduction 

The Aeronautical Mobile Airport Communications System 
(AeroMACS) is a developing standard for wireless 
aeronautical communications for airport surface operations. 
AeroMACS support safety critical communications 
applications including air traffic control, airline operations, 
and advisory information [1]. A spectrum allocation for the 
AeroMACS network was established at the World 
Radiocommunications Conference (WRC) 2007. The 
allocation provides 59 MHz of bandwidth in the 5091-5150 
MHz band. Analyses of the bandwidth requirements for 
AeroMACS have shown that at least 100 MHz of bandwidth 
will be needed in the long term. As a result, proposals for 
additional AeroMACS spectrum were submitted for 
consideration at the WRC-2012, in particular in the 5000- 
5030 MHZ band. Whether or not all or some of this band is 
allocated for AeroMACS, the need for further refinement of 
AeroMACS long term bandwidth requirements must 
continue if further spectrum allocations are to be proposed 
for consideration at future WRCs. 

The initial analyses of AeroMACS bandwidth requirements 
did not consider VHM data transmission, as the need had not 
yet been recognized. In future VHM systems now being 
researched by NASA and others, a large distribution of 
advanced on-board sensors will monitor many different 
aircraft systems while in flight. Vehicle level reasoning 
algorithms will analyze the sensor data and evaluate its 
meaning in order to determine if any action is required. 
Such a VHM system will accumulate and archive a large 
amount of data, much of which is of significance in terms of 
aircraft type and trend analysis regardless of whether any 
action was indicated by the VHM system during the flight 
and therefore must be offloaded from the aircraft. Initial 
estimates of VHM data offload requirements were developed 
to support the current WRC- 12 AeroMACS spectrum 
proposals. As VHM system development has progressed, 
vehicle level reasoning systems (VLRS) have emerged as a 
component of the overall VHM concept, but present an 
additional data requirement as they will process vehicle data 
sets that are mostly different from the VHM sensor data 
previously analyzed. 

This paper presents an analysis of the potential VLRS data 



transmission requirement for the airport surface. The 
following section provides an overview of AeroMACS and 
the current AeroMACS bandwidth requirements excluding 
VHM. That is followed by an overview of the vehicle health 
management concept and a review of recent analyses of 
VHM data requirements for AeroMACS. The next section 
describes a particular on-board vehicle health reasoning 
system currently under development and testing. The 
expected data archive requirement resulting from this system 
are then analyzed and the supporting data rates required 
from the AeroMACS airport surface communications system 
derived for typical airport sizes. The final section offers 
concluding remarks. 

2. AeroMACS Overview 


The Aeronautical Mobile Airport Communications System 
(AeroMACS) is a developing standard for wireless 
aeronautical communications restricted to the airport surface 
(stationary and mobile vehicles with wheels in contact with 
the airport surface). RTCA Special Committee 223 (SC- 
223) and EUROCAE Working Group 82 (WG-82) are 
coordinating the development of the AeroMACS standards, 
after which international standardization will occur under the 
International Civil Aviation Organization (ICAO). 

The AeroMACS network will operate within the 5091-5150 
MHz band under the Aeronautical Mobile (Route) Service 
(AM(R)S) allocation. This allocation was adopted at the 
2007 World Radiocommunications Conference (WRC-07). 
The WRC-07 decision on Agenda Item 1.3 removed the 
prior limitation in the MLS extension band for "support of 
navigation/surveillance functions” only. The AM(R)S 
designation now allows communications services that 
support safety and regularity of flight applications. The 
protected allocation for aeronautical mobile services enables 
ICAO to approve international standards for wireless mobile 
communications networks on the airport surface. In the U.S. 
the AeroMACS network can be used for both mobile users 
and fixed assets that directly support safety and regularity of 
flight. AeroMACS services can be provided to aircraft 
anywhere on the airport surface, as long as wheels are in 
contact with the surface. AeroMACS can also be used for 
communications with a variety of service vehicles and 
airport infrastructure that directly support safety and 
regularity of flightf 1] . 

RTCA SC-223 and EUROCAE WG-82 have developed the 
AeroMACS Profile draft published on December 15, 2010. 
The profile documents the adaptations required for the IEEE 
802.16-2009 standard to provide wireless data 
communication service to fixed and mobile platforms in 
AeroMACS. Included in the profile is the channelization 
plan for AeroMACS, shown in Figure 1 [2]. The two 
standards groups are now working to develop the Minimum 
Operational Performance Standards, or MOPS. 



Figure 1 - AeroMACS Channel Plan: 5 MHz channels over 
5091-5150 MHz 

User applications for transport over AeroMACS have been 
classified into the following five categories: 

• Air Traffic Management (ATM) / Air Traffic Control 
(ATC) 

• Aeronautical Information Management and 
Meteorological Data (AIM/MET) 

• Owner/Operator 

• Airport Authority 

• Airport Infrastructure 

The preliminary analysis of airport surface communications 
(previously referred to as the Airport Network and Location 
Equipment (ANLE) system) bandwidth requirements was 
prepared by the MITRE Corporation for the Federal 
Aviation Administration (FA A) in 2006, to support the 
proposal for an airport surface communications frequency 
allocation at WRC-2007[3]. This analysis was based in part 
on a airport surface communications requirements study 
communications commissioned by NASA Glenn Research 
Center in 2004 [4]. The result of the analysis was a 
preliminary estimate of 60 MHz of bandwidth required to 
support the airport surface requirement. 

The MITRE analysis considered the following applications 
for the airport surface communications system: 

• Sensor data 

o Surveillance data 

■ Airport Surveillance Radar (ASR) data 

■ Airport Surface Detection Equipment Mode X 
(ASDE-X) data from remote units (RU) to the 
multi-processor 

■ ASDE-X display data 

■ Digital Bright Radar Indicator Tower 
Equipment (DBRITE) data 

o Weather data 

■ Low Level Wind Shear Alert System 
(LLWAS) data 

■ Automated Weather Observing System 
(AWOS) / Automated Surface Observing 

■ System (ASOS) data 

■ Terminal Doppler Weather Radar (TDWR) 
data 

■ Integrated Terminal Weather System (ITWS) 
data 

■ Weather Systems Processor (WSP) data 
o Navigation and landing aid data 

■ Terminal Navigational Aids (NAY AIDS) data 
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• Automation data 

o Enhanced Traffic Management System (ETMS) 
data 

o Center-TRACON Automation System (CTAS) data 

• ATC voice (diversity path as a backup for existing 
facilities) 

• Electronic Flight Bag (EFB) data 

• Airport surface data transmission to taxiing aircraft and 
surface vehicles 

In 2009, MITRE updated this analysis, including more 
detailed analysis of the OFDMA implementation of the 
IEEE 802. 16e standard that is the basis of AeroMACS, to 
evaluate the bandwidth requirements at a large airport [5]. 
The analysis took into account long-term bandwidth 
requirements as envisioned under the Eurocontrol/FAA 
Communications Operating Concept and Requirements 
(COCR) for Future Radio System, which defines an initial 
future communications Phase 1 through the year 2020 and 
Phase 2 occurring beyond 2020 [6]. For the Phase I time 
frame, the estimated bandwidth requirement is 100 MHz. 
For Phase II, the requirement is 1 10 to 120 MHz, depending 
on AeroMACS channel bandwidth. 

Vehicle health management data requirements were not 
considered in these analyses. 

3. Vehicle Health Management and 
AeroMACS Data Requirements 


NASA’s research on vehicle health management originally 
took place under the Integrated Vehicle Health Management 
(IVHM) Project, and is now part of the Vehicle Systems 
Safety Technologies Project. These projects focus on 
reducing the impact of adverse events during flight. This 
long-term research includes the development of vehicle 
health sensors to detect and monitor the health of critical 
aircraft systems, as well as the algorithms that will interpret 
the resulting sensor data to determine the health status of the 
aircraft. Sensors for the monitoring of structural integrity, 
propulsion systems, pressure, gas, fire, and environmental 
effects are being developed to have a low weight, size, 
power and cost impact on the aircraft. They will be 
interconnected through an on-board wireless network to 
provide real time data for diagnosis, prognosis and 
mitigation algorithms intended to prevent and/or mitigate 
adverse events during aircraft flight. Adverse events include 
those that arise from system, subsystem, or component faults 
or failures due to damage, degradation, or environmental 
hazards that occur during flight. 

The new IVHM capabilities will enable the rapid detection 
and diagnosis of these adverse events (in both the hardware 
and software) essential to the safe operation of the vehicle 
and will enable the estimation of the condition severity and 
the remaining useful life with confidence bounds for the 
affected system(s). Maintenance workers, crew, adaptive 
configuration systems and other control systems can take 
advantage of the estimated remaining useful life to enhance 
the safety profile of the aircraft. While in most cases the 


detected status will influence such things as vehicle 
maintenance cycles, in more time-critical cases, immediate 
action might be necessary to avoid serious safety issues. 

The handling of the sensor data, between the point of 
generation at the sensor and the point of processing, will 
occur through an on-board wireless network combined with 
an off-board data communication link. Depending upon the 
criticality of the data and other factors, some sensor- 
generated data will be processed on the aircraft, some will be 
stored for later download and analysis while the aircraft is 
on the ground and some will be delivered off-board while 
the aircraft is in flight. 

In previous work, NASA estimated the total sensor data load 
for emerging vehicle health sensor networks and the subset 
of data required to be off-loaded from an aircraft during 
flight [7]. In this paper, NASA estimated the total sensors 
data output based on an Boeing 757-200 size aircraft and 
assessed requirements for off-board data communications 
while the aircraft was in flight. The analysis considered 
sensors and sensor categories related to NASA’s IVMH 
Project research, including: Structural Integrity; Aircraft 
Systems and Avionics Health Monitoring; Aircraft Icing 
Sensing; Propulsion System Health Monitoring; Pressure 
Sensing; Weather Condition Sensing; Gas Sensing; 
Temperature Monitoring; and Smoke and Fire Detection. 
The requirements for off-board communications as 
developed in this approach are a maximum of 742.4 kbps. 
Of this total, 259.2 kbps are real time off-board 
communications requirements, imposing maximum quality 
and availability requirements on the air-ground data 
communications link. A further 316.2 kbps are near-real 
time requirements. The remaining 167 kbps are delayed 
data requirements. 

At the request of the FAA, this work was further extended in 
a white paper to provide an estimate of VHM data 
requirements on the airport surface [8]. In this initial 
analysis, the sensor data analyzed in [7] was subjected to 
further interpretation to estimate the amounts of sensor data 
that would be expected to be off-loaded from a future VHM- 
equipped aircraft after landing. From [8]: The total data 
amount to be transmitted is roughly proportional to the flight 
time, or the time during which sensor data was being 
acquired. For example, assuming a 2 hour flight during 
which sensor data was being acquired for the entire duration, 
a total of 3.48 Gb of data would need to be transmitted off 
the aircraft on the airport surface. The transmission data rate 
required would then be dependent on the amount of time the 
aircraft is available on the surface. For example, an aircraft 
with a 30 minute turnaround time would required a data rate 
of 1.94 Mbps to offload data from a 2 hour flight under this 
scenario. 

In preparation for WRC-12, where proposals for additional 
AeroMACS spectrum in the 5000-5030 MHz band were 
submitted, additional analyses of VHM data offloading 
requirements on the airport surface were conducted, as 
reported to ICAO Aeronautical Communications Panel 
Working Group F[9]. It is important to explain the VHM 
data requirements currently being presented in support of the 
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WRC-2012 AeroMACS spectrum proposal in order to 
provide context for the additional VLRS data requirement 
derived in Section 5. In the ICAO working paper analysis, 
data rates for COCR Phase 1 and 2 time frames were 
developed, and included two components: real time data 
requirements for aircraft while operating in the 
run way/taxi way/ramp areas (similar to the in-flight data 
offload requirements developed in [7]) and delayed data 
offload requirements for data that was acquired and stored 
during flight (as initially estimated in [8]). The analysis 
assumed a 2 hour flight, an 8 minute taxi and a 54 minute 
aircraft turn-around (COCR Phase 1) or a 36 minute aircraft 
turn-around (COCR Phase 2). 

For the real time runway/taxiway/ramp component, the 
analysis assumed aircraft operating at maximum VHM data 
generation rate of 303.4 kbps 10% of the time and at the 
minimum rate of 33.9 kbps 90% of the time (rates derived 
from [7]). Assuming a maximum of 48 aircraft involved for 
COCR Phase 1 and 70 aircraft for Phase 2, the aggregate 
data rate that AeroMACS must support for this application is 
2.98 Mbps for Phase 1 and 4.26 Mbps for Phase 2 (includes 
8.05% data overhead). 

For the offload of data stored during flight component, the 
analysis assumed aircraft operating at maximum VHM data 
storage of 483.2 kbps 10% of the time and at the minimum 
rate of 5.7 kbps 90% of the time (rates derived from [7]). 
Assuming a maximum of 154 aircraft downloading stored 
VHM data for COCR Phase 1 and 222 aircraft for Phase 2, 
the aggregate data rate that AeroMACS must support for this 
application is 17.22 Mbps for Phase 1 and 34.96 Mbps for 
Phase 2. 

The total AeroMACS data load due to VHM applications is 
20.2 Mbps for Phase 1 and 39.22 Mbps for Phase 2. 

To summarize, the previously derived and reported 
AeroMACS data loads resulting from VHM data offloading 
are: 

• In-flight VHM communications [7]: 742.4 kbps per 
aircraft. 

• Airport surface VHM communications, initial estimate 
[8]: 1.94 Mbps. 

• Airport surface VHM communications, extended 
analysis [9]: 20.2 Mbps for Phase 1 and 39.22 Mbps 
for Phase 2. 

Vehicle level reasoning is the next step in developing 
comprehensive VHM systems. Vehicle level reasoning 
system (VLRS) algorithms are under development to 
analyze various aircraft status indicators and health sensor 
data and evaluate its meaning in order to determine if any 
action is required while the vehicle is in flight. Eventually, 
complex systems are envisioned to evaluate the outputs of 
thousands of sensors on future aircraft. 

However, initial versions of VLRS now under development 
and testing are relying on currently available sensors and 
aircraft system monitors. These VLRS have the potential to 


be implemented within the next several years, well before 
the advanced sensor systems being developed by NASA and 
others are available. The VLRSs will themselves be 
archiving a separate data set representing data gathered and 
analyzed on-board, as well as the resulting processed 
outputs. It is unknown to what extent future VLRS systems 
and advanced sensors systems will converge into a single 
system. Since previous estimates of aircraft VHM data off- 
loading requirement on the airport surface were based 
primarily upon future VHM sensor installations, and there is 
a likelihood that the processing results will remain a separate 
entity from the sensor outputs and also require archiving, the 
VLRS data sets represent an additional AeroMACS data 
load requiring analysis. 

VLRS is described in the next section, and the VLRS 
AeroMACS communications requirement follows. 

4. Vehicle Level Reasoning System 


The VLRS system is intended to prevent adverse events 
during flight by searching for potential system faults and 
analyzing the progression of faults and their severity. This is 
accomplished through a number of reasoning algorithms 
which make use of both current aircraft system monitoring 
data and historical data. 

Two NASA Research Announcement awards were made for 
VLRS system research and development. Honeywell 
International, Inc. is developing the Vehicle Integrated 
Prognostic Reasoner (VIPR). VIPR consists of an on-board 
system analyzing the inputs from various aircraft sensors, as 
well as past history of the aircraft health [10]. The results of 
this work to date have provided a basis for Honeywell to 
estimate that the VIPR system will produce 2.76 MB of 
VHM per flight hour that would be downloaded upon 
aircraft arrival. 

The Boeing Company received the other NASA VLRS 
award. The Boeing system relies on the in-flight off-board 
communication of VHM data for processing on the ground. 
The progress to data has not yet been analyzed for revising 
or extending the in-flight off-board data requirements 
presented in [7]. 

From [10], VLRS addresses scenarios involving a fault or 
faults progressing in time and severity such that the effects 
are felt throughout the aircraft and its operations. For the 
VIPR development, the following categories are described: 

1. Faults whose severity increases with time. 

2. Binary repeating faults whose repetition increases with 
time. 

3. Faults whose effects spread throughout the aircraft with 
time. 

The VIPR system is based on Aircraft Diagnostic and 
Maintenance System and the Joint Strike Fighter Prognostic 
Health Management system as the prognostic engines. 
Interpretation of the prognostic outputs involves a multitude 
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of time scales as well as coverage of aircraft systems and 
their interactions. 

Data mining and machine learning techniques are use to 
characterize interactions between components and systems 
and the potential chain of events. The underlying algorithms 
establish the parametric relationships associated with the 
various entities in the VIPR fault propagation system model 
and discover new relationships from operational data. 

As an on-board system intended to operate during flight, the 
flight crew is the primary consumer of VIPR outputs. A 
secondary set of consumers is the airline line maintenance 
and repair depot maintainers. 

5. Analysis of VLRS Communications 
Requirements for AeroMACS 


The VIPR system described in the previous section is used 
as the model for estimating the VLRS communications 
requirements for AeroMACS. The VIPR concept is 
currently being evaluated using data from a fleet of 30 
aircraft. The VIPR thus gathers inputs from currently 
available avionics diagnostics, sensors and system monitors. 

As previously noted, the initial versions of VLRS will be 
gathering and processing data different from the types of 
advanced vehicle health sensor data considered for VHM 
data offloading requirements in [7-9]. As new vehicle health 
sensors are deployed, number of parameters monitored will 
increase. However, the data offload requirement resulting 
from these new sensors has been considered in the previous 
AeroMACS VHM requirements analyses. 

VIPR operates by collecting -182 aircraft system health 
status parameters at varying sampling rates, using the 
ARINC 717 data recording format consisting of 512 12-bit 
word frame, one frame every second. This translates to 3600 
frames, or 2.76 MB per flight hour[ll]. The figure of 2.76 
MB per flight hour represents the best currently available 
figure used for deriving VLRS AeroMACS data loading. 

Upon arrival of an aircraft on the airport surface, stored 
VLRS data will be downloaded for archiving. Using the 
figure of 2.76 MB per flight hours, a maximum airport 
surface data rate estimate can be derived. 

The estimate is dependent on the volume of flight operations 
at a given airport. In the ICAO working paper analysis 
discussed above, projected numbers based on COCR Phase 1 
and 2 were used to derive estimates of maximum 
AeroMACS VHM data load. 

Employing a similar method as in [9], namely assuming a 
two hour flight, an 8 minute taxi and a 54 minute aircraft 
turn-around (COCR Phase 1) or a 36 minute aircraft turn- 
around (COCR Phase 2), we can obtain, by dividing the total 
data load in bits by the taxi and turnaround time: 

Phase 1: 

(2.76 MB/hour*2 hours*8 b/B)-^(54+8 min) = 11.87 kbps 


Phase 2: 

(2.76 MB/hour*2 hours*8 b/B)-H36+8 min) = 16.73 kbps 

To obtain the aggregate AeroMACS VLRS loading due to 
all aircraft at an airport, the maximum aircraft numbers from 
COCR are used (154 for Phase 1, 222 for Phase 2): 

Phase 1: 11.87 kbps*154 aircraft = 1.828 Mbps 

Phase 2: 16.73 kbps*222 aircraft = 3.713 Mbps 

These figures, while representing roughly an order of 
magnitude less of an AeroMACS data load than the VHM 
data estimated by the ICAO working paper [9], are 
nevertheless significant in terms of the total available 
AeroMACS bandwidth. 

In order to compare the VLRS data offload requirement 
based on the COCR projections with current airport traffic 
density, we analyzed a typical medium sized airport, 
Cleveland Hopkins International Airport (CLE) and a very 
large airport, Chicago O’Hare International Airport (ORD). 
Using the published Monday flight schedule for CLE (June, 
2010) and ETMS data for ORD (Monday, 14 June, 2010), 
the time length of arriving flights was tabulated for each 10 
minute increment throughout the day (the total of the flight 
times for each flight arriving within a particular 10 minute 
increment). For example, three flights arriving in the ten 
minute time interval 00:40 through 00:50 that had flight 
times of 60 minutes, 90 minutes and 120 minutes 
respectively would yield a time length of arriving flights of 
270 minutes. This provided a table of total flight arrival 
minutes. The total volume of VHM data to be downloaded 
during each 10 minute increment is calculated using the 2.76 
MB per flight hour figure multiplied by 2.76 MB per 60 
minutes. Figures 2 and 3 show these results. 

The peak airport surface data rate (in kbps) that must be 
supported for the VHM system based on the VIPR design is 
calculated by dividing the peak volume in MB by 600 
seconds (per 10 minute interval), and multiplying by 8 bits 
per byte. For CLE, the peak data volume from Figure 2 is 
66.47 MB. The resulting peak data rate required to support 
this data is 66.47 MB *8 b/B^-600 sec = 886.3 kbps. For 
ORD, the peak data volume from Figure 3 is 155.89 MB. 
The resulting peak data rate required at ORD is thus, 155.89 
MB *8/600 = 2078.5 kbps. This peak data rate does not 
include network/protocol overhead or security overhead, and 
is based on June, 2010 traffic levels. 

Thus, to support VLRS type VHM data downloading on the 
airport surface, AeroMACS will need to provide at least 1 
Mbps of peak capacity for medium sized airports, and in 
excess of 2 Mbps for large airports for current airport traffic 
density. The data requirement derived for ORD in 2010 is 
very similar to the COCR Phase I calculation using the 
method in [9]. The COCR Phase 2 projection for beyond the 
year 2020 taking into account smaller aircraft turnaround 
times and a higher aircraft density increases the maximum 
data load by 79% compared to 2010. 


5 



CLE Arrival Flights VHM Data Download per 10 Minute 

Increments, MB 
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Figure 2 - Total VHM Data Download Requirements for CLE, MB per 10 minute Increment, June 2010 



Figure 3 - Total VHM Data Download Requirements for ORD, MB per 10 minute Increment, June 2010 


6. Conclusion 


The AeroMACS airport surface communications system 
standards are currently under development. AeroMACS, 
based on the IEEE 801.16e standard, will provide wireless 
communications coverage for airport surface operations for 
safety related aviation applications. The WRC-2007 
allocated 59 MHz of bandwidth for AeroMACS. However, 
studies indicate that this allocation is inadequate to enable all 
of the projected AeroMACS applications. Hence, additional 


allocations are being proposed, requiring more detailed 
analysis of the data communications requirements of 
AeroMACS applications to support the allocation proposals. 

Vehicle health management has been recognized as an 
important future AeroMACS application. Significant 
research and development work for VHM within the last 
decade will enable the future implementation of VHM 
systems. Aircraft VHM is being advanced through the 
development of advanced sensors as well as VLRSs to 
analyze the outputs of sensors and system monitors in real 
time to assess the current state of vehicle health and enable 
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mitigating actions in case of detected faults and progressing 
failures which threaten the safety of the aircraft. The data 
produced by both on-board sensors and VLRS systems is of 
sufficient value for further analysis that it is anticipated to be 
archived in ground-based facilities for that purpose. This 
presents a significant data communications requirement for 
both in-flight and airport surface communications systems. 

In this paper, we have presented the analyses of VHM 
airport surface data loads currently being used to support 
AeroMACS frequency allocation proposals. These analyses 
estimate a requirement of approximately 20 Mbps in the near 
term (up to 2020) and approximately 40 Mbps in the far term 
(beyond 2020). We then analyzed additional VHM 
AeroMACS data loading requirements resulting from the 
advent of VLRSs, and showed that including the VLRS data 
requirement increases the overall VHM AeroMACS data 
load requirement by approximately 10%. This represents a 
significant additional requirement which must be considered 
in deriving the spectrum requirements for AeroMACS. 
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